package com.zjl.Zookeeper.第06章_源码分析;

/**
 * 和 Paxos算法 区别就是，ZAB算法 只有一个 Proposer 提议者 也就是 LEADING
 *      LEADING：领导者状态
 *      FOLLOWING：跟随者状态
 *
 *  Zab协议包括两种基本的模式:消息广播、崩溃恢复。
 * (1) 客户端发起一个写操作请求。
 * (2) Leader服务器将客户端的请求转化为事务Proposal提案，同时为每个Proposal分配一个全局的ID，即zxid。
 * (3) Leader服务器为每个Follower服务器分配一个单独的队列，
 *      然后将需要广播的Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。
 * (4) Follower接收 到Proposal后，会首先将其以事务日志的方式写入本地磁盘中，
 *      写入成功后向Leader反馈一个Ack响应消息。
 * (5) Leader接收到超过半数以上Follower的Ack响应消息后，即认为消息发送成功，可以发送commit消息。
 * (6) Leader向所有Follower/广播commit消息，同时自身也会完成事务提交。Follower 接收到commit消息后，会将上一条事务提交。
 * (7) Zookeeper采用Zab协议的核心，就是只要有一台服务器提交了Proposal,就要确保所有的服务器最终都能正确提交Proposal。
 *
 * 1)假设两种服务器异常情况:
 *      (1)假设一个事务在Leader提出之后，Leader挂了。
 *      (2)一个事务在Leader上提交了，并且过半的Follower都响应Ack了，但是Leader在Commit消息发出之前挂了。
 * 2)Zab协议崩溃恢复要求满足以下两个要求:
 *      (1)确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交。(已经产生的提案，Follower必须执行)
 *      (2)确保丢弃已经被Leader提出的，但是没有被提交的Proposal。(丢弃胎死腹中的提案)
 *
 * Leader选举:根据上述要求，Zab协议 需要保证选举出来的Leader需要满足以下条件:
 * (1)新选举出来的Leader:不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点。
 * (2)新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。
 *
 * Zab如何数据同步:
 * (1)完成Leader选举后，在正式开始工作之前(接收事务请求，然后提出新的Proposal)，
 *      Leader服务器会首先确认事务日志中的所有的Proposal是否已经被集群中过半的服务器Commit。
 * (2)Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal,并且能将所有已经提交的事务Proposal
 *      应用到内存数据中。等到Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过，并且应用到内存数据中以后，
 *      leader才会把该Follower加入到直正可用的Follower列表中，
 *
 */
public class A2_ZAB算法 {
}
